Summary

Make the agent workspace worktree-native so multiple parallel sessions can cook features in the same repo without stepping on each other.

Today every session shares one git checkout per repo at ~/.datamachine/workspace/<repo>/. Two sessions branch-switching at the same time corrupts each other's work — the classic "agent stepped on itself" pattern.

After this change, each branch lives in its own directory:

```
~/.datamachine/workspace/
├── data-machine-code/ ← primary, hands-off by default
├── data-machine-code@fix-foo/ ← worktree for fix/foo
└── data-machine-code@feat-bar/ ← worktree for feat/bar
```

The <repo>@<branch-slug> naming makes the on-disk directory the handle. All existing read/write/git abilities transparently accept either form. No new flag plumbing through every ability.

What's in here

4 new abilities (CLI-only by default; list is REST-readable):

• datamachine/workspace-worktree-add — {repo, branch, from?} → creates <repo>@<slug> as a git worktree, checks out branch (creating off from if it does not exist locally; default origin/HEAD).
• datamachine/workspace-worktree-list — {repo?} → branches, heads, dirty counts. Distinguishes primary vs worktree.
• datamachine/workspace-worktree-remove — {repo, branch, force?} → refuses if dirty unless forced.
• datamachine/workspace-worktree-prune — runs git worktree prune across all primaries.

1 new CLI subcommand:

```
wp datamachine-code workspace worktree add [--from=]
wp datamachine-code workspace worktree list [] [--format=json]
wp datamachine-code workspace worktree remove [--force]
wp datamachine-code workspace worktree prune
```

Handle resolver — Workspace::parse_handle() splits <repo>@<slug> into components. Called by Workspace::get_repo_path() and resolve_repo_path(), so WorkspaceReader and WorkspaceWriter work on either primary or worktree handles with zero call-site changes.

Branch slug — / becomes - (fix/foo-bar → fix-foo-bar). Anything outside [A-Za-z0-9._-] is stripped; runs of dashes collapse.

Primary read-only by default — mutating ops (git pull|add|commit|push) on a bare <repo> handle now require --allow-primary-mutation (CLI) / allow_primary_mutation: true (ability input). Codifies the discipline that the primary checkout tracks the deployed branch and shouldn't be touched by parallel agents.

Policy updates:

• clone rejects @-suffixed names — that suffix is reserved for worktrees.
• remove refuses to delete a primary that has linked worktrees attached (with helpful error listing them).
• git push only enforces fixed_branch on the primary checkout. Worktrees may push any branch — that's the whole point of having them.

Tests

• tests/smoke-worktree-handles.php — pure-PHP unit smoke for parse_handle() and slugify_branch(). No WP bootstrap required. 32/32 passing.
• tests/TESTING.md — manual end-to-end checklist: clone → worktree add → edit → commit → push → remove, plus all the negative cases (dirty refuse, primary mutation guard, clone-with-@, primary-with-linked-worktrees).

Backward compatibility

All bare <repo> handles continue to resolve to the primary checkout. The only behavioral break is the new primary mutation guard — existing automation that mutates the primary needs --allow-primary-mutation. That's the intended default-deny.

Why this matters

Today, parallel agent work in the same repo is unsafe. After this lands, every Discord thread / kimaki session can have its own worktree handle for the repo it's editing. Multiple features cooked at once, isolated on disk, reviewed as separate PRs. Unblocks the autonomous-parallel-agent story end-to-end.

Design doc: see the "Workspace Worktrees Design" wiki article in the linked Intelligence site.